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REMARKS 

By this amendment, no claims have been added or cancelled, and Claims 1 and 
10-15 have been amended. Hence, Claims 1 and 10-15 are pending in the application. 

SUMMARY OF THE REJECTIONS 

Claim 1 has been rejected under 35 U.S.C. § 103(a) as allegedly being obvious 
over "The X-Bone" by Joe Touch ("Touch") in view of "IP Multicast in RealSystem G2" 
by V. Thomas ("Thomas"). Claims 12-13 have been rejected under 35 U.S.C. § 103(a) as 
allegedly being obvious over Touch in view of Thomas in view of "An Application Level 
Video Gateway by Amir et al. ("Amir"). 

Claims 1, 10, and 14-15 have also been rejected under 35 U.S.C. § 103(a) as 
allegedly being obvious over "Policy Tree Multicasting Routing: An Extension to Sparse 
Mode Source Tree Delivery" by H. Hodel ("HodeF') in view of Thomas. 

The Applicant respectfully traverses. 

THE PENDING CLAIMS ARE PATENTABLE OVER THE CITED ART 

Even if the cited art were to be properly combined, each of the pending claims 
recites a combination of features that is not disclosed, taught, or suggested by the cited 
art. 

Claim 1 

Claim 1, as amended, recites: 

A method comprising performing a machine-executed operation involving 
instructions, wherein the machine-executed operation is at least one of: 

A) sending said instructions over transmission media; 

B) receiving said instructions over transmission media; 

C) storing said instructions onto a machine-readable storage medium; and 

D) executing the instructions, 

wherein said instructions are instructions which, when executed by one or 
more processors, cause: 

receiving a signal, originating from a sender, which indicates 
an intention of the sender to send packets to an overlay 
group that includes a set of computers; 

determining whether the sender has permission to send packets 
to the overlay group; 

if the sender has permission to send packets to the overlay group, 
then performing the steps of: 
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determining whether a received packet, from the sender, is 
associated with the overlay group; 

determining whether to send the received packet to a 

particular computer, in the set of computers, via 
a multicast connection or a unicast connection 
based, at least in part, on data indicating a 
transport preference of the particular computer; 

upon determining that the received packet should be sent to 
the particular computer via the multicast 
connection, routing the received packet to the 
particular computer using a native routing protocol 
to send the received packet by multicasting; and 

upon determining that the received packet should be sent to 
the particular computer via the unicast connection, 
routing the received packet to the particular 
computer using the native routing protocol to send 
the received packet by unicasting. 

At least the above-bolded features of Claim 1 are disclosed, taught, or suggested 
by the cited art. 

Touch, Thomas, and Hodel are each cited to show portions of Claim L Touch is 
directed towards an approach (referred to therein as an X-Bone) for implementing an 
overlay network. Touch, however, does not provide many details about how the X-Bone 
approach actually works. For example, Touch is silent with respect to how senders send 
packets to an overlay group in the X-Bone approach. 

Thomas lacks any teaching or suggestion of an overlay network. Instead, Thomas 
is directed towards an approach for enabling a client to inform a server that the client did 
not receive a packet sent from the server to the client using a multicast connection. In 
Thomas, if the client does not receive a packet sent from the server to the client using a 
multicast connection, the client initially attempts to use a back-channel to inform the 
server that the client did not receive the packet. If the client's attempt to contact the 
server using the back-channel is unsuccessful, then the client will then attempt to contact 
the server using a standard unicast live connection. Importantly, in Thomas, neither the 
server nor the client ever make a determination as to whether to send a received packet by 
a multicast connection or a unicast connection based on a transport preference of the 
destination of the packet. 
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Hodel lacks any teaching or suggestion of an overlay network. Instead, Hodel is 
directed towards an approach for performing multicast routing. 

There are significant differences between the features of Claim 1 and the 
approaches of the cited art. Embodiments of the invention, while enabling packets to be 
sent to a destination computer in an approach that employs native multicasting, provide 
additional functionality and features not available through prior art approaches for 
performing multicasting. For example, the Applicant's specification (at page 8, line 28- 
page 9, line 5) teaches: 

To maximize the congruence between the OMN architecture and the 
existent EP Multicast service interface, hosts use the standard IP Multicast 
interface to inject data packets into and receive packets from an OMN. In 
one embodiment of the invention, overlay multicast senders (or proxies for 
the sender) explicitly signal to the network their intention to transmit. 
This is unlike IP multicast, where hosts may simply send packets 
addressed to a Class D multicast group without any explicit signaling. As 
part of this dialogue, the sender describes the channel that it intends to use 
(e.g., UDP multicast, UDP unicast, or TCP), and, once negotiated, 
overlay-enabled multicast packets may be sent into the network. This 
sender setup process may fail if the source does not have administrative 
permission to send. Thus, OMN sources can be tightly controlled in 
contrast to normal IP multicast, which provides no control over senders, 
(emphasis added). 

Claim 1 recites the features of "receiving a signal, originating from a sender, 
which indicates an intention of the sender to send packets to an overlay group that 
includes a set of computers" and "determining whether the sender has permission to send 
packets to the overlay group." Touch cannot disclose, teach, or suggest these features 
because Touch is silent with respect to how packets are sent to an overlay group. 
Specifically, Touch lacks any teaching or suggestion of either (a) receiving a signal, 
originating from a sender, that indicates an intention of the sender to send packets to an 
overlay group, or (b) determining whether the sender has permission to send packets to 
the overlay group. Consequently, Touch cannot disclose, teach, or suggest these features. 

Thomas and Hodel cannot disclose, teach, or suggest these features, as Thomas 
and Ho del each lack any teaching or suggestion of an overlay group, let alone (a) 
receiving a signal, originating from a sender, that indicates an intention of the sender to 
send packets to an overlay group , or (b) determining whether the sender has permission to 
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send packets to the overlay group . Even if, arguendo, a multicast group may be 
construed to be an overlay group, as shown above in the quoted portion of the Applicant's 
specification, according to prior approaches for performing multicasting, hosts may 
simply send packets addressed to a multicast group without any explicit signaling or 
permission. As a result, Thomas and Hodel would each teach away from these claimed 
features since (a) the sender is not required to signal their intention to send packets to a 
multicast group and (b) the sender is not required to have any permission level to send to 
a multicast group. Consequently, Thomas and Hodel each cannot disclose, teach, or 
suggest these claimed features. 

Therefore, as each of Touch, Thomas, and Hodel fail to disclose, teach, or suggest 
the features of "receiving a signal, originating from a sender, which indicates an intention 
of the sender to send packets to an overlay group that includes a set of computers" and 
"determining whether the sender has permission to send packets to the overlay group" 
recited in Claim 1, even if one or more of Touch, Thomas, and Hodel were to be properly 
combined the resulting combination would still fail to disclose, teach, or suggest these 
claimed features. 

Claim 1 also recites the element of "determining whether to send the received 
packet to a particular computer, in the set of computers, via a multicast connection or a 
unicast connection based, at least in part, on data indicating a transport preference of the 
particular computer." The portion of Thomas cited to show this element (page 2, section 
entitled "Back-Channel Multicast) does not involve any determination as to whether to 
send a received packet to the particular computer via a multicast connection or a unicast 
connection. 

For example, the server of Thomas always sends a packet to the client via a 
multicast connection. If a packet, send from the server to the client using the multicast 
connection, is not received by the client, then the client will always try to initially connect 
to the server using a back-channel. The back-channel is characterized by Thomas as a 
multicast connection. If the client is unable to connect to the server via the back-channel 
to inform the server that the client did not receive a packet, then the client will always try 
to connect via a standard unicast live connection. Thus, in Thomas, while the client may 
connect to the server either by the back-channel or the standard unicast live connection, 
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the client never has to decide which of the back-channel connection or the standard 
unicast live connection the client should use to contact the server. As a result, the client 
never makes a determination as to whether to send a packet to the server via a multicast 
connection or a unicast connection, since the client never has the option of using one or 
the other. Similarly, since the server of Thomas always sends packets via a multicast 
connection, the server cannot makes a determination as to whether to send a packet to the 
client via a multicast connection or a unicast connection. 

Further, the portion of Thomas cited to show this element (page 2, section entitled 
"Back-Channel Multicast) also does not involve data that indicates a transport preference 
of a particular computer. As explained above, the client of Thomas is not provided an 
option as to how it would like to receive packets. As a result, the server of Thomas does 
not store any data that indicates a transport preference of the client. Further, the server of 
Thomas always sends packets to the client using a multicast connection. Consequently, 
no portion of Thomas discloses, teaches, or suggests the element of "determining whether 
to send the received packet to a particular computer, in the set of computers, via a 
multicast connection or a unicast connection based, at least in part, on data indicating a 
transport preference of the particular computer." 

As at least one element featured in Claim 1 is not disclosed, taught, or suggested 
by the cited art, either individually or in combination, it is respectfully submitted that 
Claim 1 is patentable over the cited art and is in condition for allowance. 

Claims 10-15 

Claims 10-15 are dependent claims, each of which depends (directly or indirectly) 
on Claim L Each of Claims 10-15 is therefore allowable for the reasons given above for 
the claim on which it depends. In addition, each of Claims 10-15 introduces one or more 
additional limitations that independently render it patentable. However, due to the 
fundamental differences already identified, to expedite the positive resolution of this case 
a separate discussion of those limitations is not included at this time, although the 
Applicants reserve the right to further point out the differences between the cited art and 
the novel features recited in the dependent claims. 
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CONCLUSION 



For the reasons set forth above, it is respectfully submitted that all of the pending 
claims are now in condition for allowance. Therefore, the issuance of a formal Notice of 
Allowance is believed next in order, and that action is most earnestly solicited. 

The Examiner is respectfully requested to contact the undersigned by telephone if 
it is believed that such contact would further the examination of the present application. 

To the extent necessary, a petition for an extension of time under 37 C.F.R. § 
1.136 is hereby made. Please charge any fee shortages or credit any overages to Deposit 
Account No. 50-1302. 



Respectfully submitted, 



HICKMAN PALERMO TRUONG & BECKER LLP 



ChristopherSrBrokaw 
Reg. No. 45,620 
Date: January 24, 2006 




2055 Gateway Place Suite 500 
San Jose, California 95110-1089 
Telephone: (408) 414-1080 ext. 225 
Facsimile: (408)414-1076 



CERTIFICATE OF MAILING 



I hereby certify that this correspondence is being deposited with the United States Postal 
Service as first class mail in an envelope addressed to: Mail Stop AF, Commissioner for 
Patents, P.O. Box 1450, Alexandria, VA mi3-1450. ^. / /I 




On January 24. 2006 



B; 
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